Subject: Minor nits in DLUR Spec.

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Mon, 17 Oct 94 17:13:47 EDT

I'm moving this discussion from the DLUR mail exploder (which should
normally be inactive) to the Reference SIG mail exploder, where
ownership of the DLUR document resides.  My responses are included in
Jim's note.

Ed
     ------------------------------------------------------------
From: "jim (j.) cobban" <[email-masked]>
Sender: "jim (j.) cobban" <[email-masked]>
Message-Id:  <"8681.Mon.Oct.17.15:19:22.1994"@bnr.ca>.
To: [email-masked]
Cc: "denis (d.r.) fortier" <[email-masked]>
Subject:  Minor nits in DLUR Spec.

On page 8-3 of DLUR-6 in section 8.1.4 the first sentence refers to "the SLU
name specified in the NS header".  A BIND is not an NS RU so it does not have
an NS header.

  >>> Thanks for pointing this out in time (files should be frozen
  >>> tomorrow).  What if I change it to "the name specified in the RU"?

In appendix D, before this is published could we fix up the unresolved
references to header RUSPARS and table CV?

  >>> This appendix uses the actual source from the Formats document.
  >>> In fact, when the next edition of Formats is published, I'll
  >>> remove all the merged formats from the appendix, leaving only
  >>> those that come after that edition.  It doesn't seem worth it
  >>> to try to create a cross-chapter reference in a different book
  >>> altogether for a transient section.

On page D-26 in the description of subfield X'93' the destination dial
address should permit up to 15 digits for E.163 and 17 digits for E.164.
Those are limits dictated by the international standards, and we should not
arbitrarily ignore them.  This is my only substantive concern.

  >>> This is not a nit; it deserves investigation and SIG review, so I
  >>> won't try to rush it into this week's edition but deal with it in
  >>> a timeframe similar to the non-canonical format changes.  By the
  >>> way, there is a calling identification number in subfield X'94'
  >>> which is also defined as an E.160 circuit-switched network
  >>> address.  Does your concern apply to it also?

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 18 Oct 1994 10:44:00 -0400

In message "Minor nits in DLUR Spec.", 

>  >>> tomorrow).  What if I change it to "the name specified in the RU"?

That is fine.  I don't think there is any actual ambiguity.

>  >>> address.  Does your concern apply to it also?

The value in subfield X'94' does not specify a length limitation so the
concern does not apply.  Also you will note that the value in subfield X'94'
explicitly specifies that the address is always reported in international
format.

If there is no urgency, I will expand on the theme.

The value in subfield X'93', in addition to the non-standard length
restriction, does not explicitly specify in which format the address is
expressed.  International format, starting with the country code as in
subfield X'94', is an absolute address.  National format is relative, that is
it consists of the actual dialing digits that you would emit from within a
particular country.  For destinations within the NANP the international
format number and the North American national number are the same, for
example 19192545515.  That is because the country code for the NANP is 1.
However for destinations outside North America the numbers are always
different.  For example a number in (outer) London in international format 
would be 44813661177 but the North American national format would be
(typically) 01144813661177 (note 14 digits!).

The advantage of using the national format is that the dialer can generally
use the digit stream directly.  The international format requires that the
dialer parse out the country code, and possibly some digits past that,
compare it to where it is located, and emit an appropriate escape
sequence.  However national format numbers cannot be exchanged across
numbering plan (national except in the NANP) boundaries.  Within most
countries (including parts of North America) even national format numbers
require some editing.  Until quite recently in North America you
could not dial 1+areacode to call a phone number in your own area code,
particularly if it was not long distance, a recorded voice would come on and
say "Dialing 1 plus the area code is not necessary ...".  As a result the
phone numbers generally coded in switched major nodes in VTAM are
topocentric, they can only be used from one particular location because they
omit area codes and long-distance escapes.

I propose that the wording of this portion of subfield X'93' should read:

"Destination dial address: E.160 circuit-switched network address of the
destination starting with the country code encoded in packed form, two
	    ------------------------------
decimal digits to the byte.  If the dial address contains an odd number of
		      ----
digits, the low-order half-byte of the byte containing the last (low-order)
digit contains X'C'."

Note that the existing version of the description of this option, in both
subfield X'93' and X'94' inconsistently uses both ISO-speak (octet) and
IBM-speak (byte).  Since this is a standard for use in networks oriented to
IBM data processing, I suggest that "byte" should be used exclusively.

I feel that this is an appropriate topic for the new working group on public
data network interfaces.